It is known that network operators need to monitor and/or to document for subsequent proof their fulfillment of SLAs (“service level agreements”) that they have made with their clients. In SLAs of this kind, the clients are guaranteed specific data rates for their data traffic that do not necessarily need to be constant. This is the case in particular when the network operator has guaranteed the provision of data rates that are above specific threshold values and when these data rates are requested by the client. It is possible, for example, for a client to be guaranteed a data rate having a threshold value of 10 Mbit/s for 50% of its data traffic and a threshold value of 20 Mbit/s for the remaining 50% of its data traffic. If these data rates exceptionally could not be provided on account of a particularly high network utilization, the client would be able to make a claim against the network operator on the basis of the agreement. In order to counter these claims, it is expedient for the network operator to monitor the utilization of the first connection provided for the client, which is proportional to the guaranteed data rate.
In this case, systems known so far do not directly provide any parameters, in particular the achievable data rate, for recording. Although it is possible to utilize the system, as a test, up to the load limit, this is impossible during normal operation since it has a negative influence on not only the individual connection but rather on the entire system. At worst, load tests of this kind contribute to the inability to meet contractually agreed values in other parts of the overall system. There are currently two approaches for monitoring the current availability and/or the utilization:                On the one hand, the currently used data rate on the first connection can be directly measured at the destination. If said rate is above the agreed threshold value, the SLA is deemed to be met. However, if the data rate is below the threshold value, it is unclear whether the client is currently requesting too low a data rate, or whether the system is unable to provide a desired higher data rate. Using this approach, it is therefore not possible to differentiate between whether the client is requesting a data rate that is below the agreed threshold value and the system is providing this data rate, or whether the system can currently only provide a lower data rate that is below the threshold value, although the client actually requires a higher data rate. This approach is therefore inadequate for monitoring the SLA.        On the other hand, as already mentioned above, in periods of low loading, within the context of a load test, an additional load can be introduced into the system up to the load limit in order to assess the achievable data rate. However, since the currently available data rate is unknown, an artificially generated additional load is applied to the system up to the full utilization, with the result that a portion of the actual payload cannot be processed. Moreover, this artificially generated load affects other regions of the overall system, and therefore agreed SLAs can no longer be met in other regions of the overall system.        
Known methods are based on direct intervention in the system and on measuring intrasystem parameters, it being possible, for example, for packet losses in the event of an overload, or two-way propagation delays, to be determined as parameters of this kind. Measurements using special packets of different sizes are also known, which measurements make it possible to measure subsystems (“variable packet size probing”). Other methods are based on absolute one-way propagation delay measurements or on measuring relative propagation delays between packets in the payload stream. In any case, all the known methods presuppose that the payload transmission and the monitoring of the overload situation take place in the same logical connection.
In methods having direct intervention in the existing system, and when measuring intrasystem parameters, the system has to be modified from time to time since it is exceptional for a system to be able to determine the current maximum available data rate for a logical connection and report this to the outside. In the case of systems having a plurality of subsystems, said subsystems each have to support different configurations of logical connections. Finally, the achievable data rate on a logical connection is usually dependent not only on external system parameters, but also on the amount of data transmitted on the other logical connections.
The methods that are based on measuring packet losses in the event of an overload are similar to conventional Transmission Control Protocol (TCP) methods. Said methods proceed from the assumption that no packet losses occur as long as the connection is operated below the utilization limit. However, in systems that inherently operate with packet losses, this assumption is only inadequately fulfilled. Using TCP on the data connection itself also results in the control mechanisms keeping the packet losses low by implicitly reducing the data rate. This again makes differentiation from the event of lower data rate demand difficult.
The methods that are based on measuring two-way propagation delays are also part of the (optional) TCP mechanisms for controlling data amounts. For this purpose, it is necessary to modify the payload headers. Nonetheless, fluctuating propagation delays influence the results. Moreover, monitoring specific data rate threshold values is difficult in all methods based on propagation delay, since the correlation between the relative system utilization and the changes in the propagation delays is indirect and can only be determined quantitatively to an extent.
The above-mentioned “variable packet size probing” is imprecise and requires the insertion of special data packets of a not insignificant size, which packets thus cause a significant additional load.
In addition to the need for precise time references at the end points, methods that are based on one-way propagation delay measurements presuppose that queues are the sources of delays and delay changes in the overall system. However, this can be presupposed only in a few systems. Thus, mobile communications systems, specifically, use connections having markedly different propagation delays, between which it is also necessary to swap during the lifetime of a connection. Furthermore, the payload has to intervene in the connection in order to introduce markers for determining the propagation delays.
Finally, methods based on measuring relative propagation delays also require packets to be inserted into the payload stream. Since methods of this kind react in a sensitive manner even to changes in the payload throughput that are below the utilization limit, they are not suitable for monitoring the utilization of a connection to be tested.